home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1231 < prev    next >
Encoding:
Text File  |  1996-08-06  |  4.2 KB  |  142 lines
  1. Newsgroups: comp.lang.c++
  2. Path: ncrgw2.ncr.com!ncrhub6!daynews!falcon!news
  3. From: Dick Menninger <Dick.Menninger@DaytonOH.ATTGIS.COM>
  4. Subject: Re: Exceptions vs. assertions
  5. X-Nntp-Posting-Host: 149.25.99.44
  6. Message-ID: <DKxrB1.63K@falcon.daytonoh.attgis.com>
  7. Sender: news@falcon.daytonoh.attgis.com (News administrative Login)
  8. Reply-To: Dick.Menninger@DaytonOH.ATTGIS.COM (mennid)
  9. Organization: AT&T Global Information Solutions
  10. X-Newsreader: DiscussIT 2.5.1.3 for MS Windows [AT&T Software Products Division]
  11. References: <4ci0on$77p@news2.ios.com>
  12. Date: Tue, 9 Jan 1996 22:47:24 GMT
  13.  
  14.  
  15. > ==========lalit gidwani, 1/4/96==========
  16. > 
  17. > Dick Menninger (Dick.Menninger@DaytonOH.ATTGIS.COM) wrote:
  18.  
  19. [Stuff deleted] 
  20.  
  21. > Thanks Dick!
  22.  
  23. >      I have a few simple lines of code. Do you think
  24. > the C++ exception mechanism has been properly used here:
  25.  
  26. > class SaveError;     // exception class
  27.  
  28. > void GetDataFromScreen() throw();
  29. > void SaveDataInDatabase() throw( SaveError );
  30. > void SaveCurrentInvoice() throw( SaveError );
  31.  
  32. As long as these functions all catch all exceptions
  33. and convert them into SaveError, this is OK.
  34. Otherwise, an exception from allocation somewhere
  35. will terminate the program without telling the user. 
  36.  
  37. > int main( int argc, char **argv )
  38. > {
  39. >      /*****************
  40. > 
  41. >           Send the selected invoice to screen and
  42. >           wait for user to say he wants to
  43. >           save the current invoice.
  44. > 
  45. >      ******************/
  46. > 
  47. >      try
  48. >      {
  49. >           SaveCurrentIncoice();
  50.  
  51. Do you want to tell user success here?
  52.  
  53. >      }
  54. >      catch( SaveError se )
  55. >      {
  56. >           // send error message to the user
  57. >      }
  58. > 
  59. > }// main
  60.  
  61. From the limited specification provided, it is not
  62. clear at all whether this is the best expression
  63. of the problem.  It may make more sense for
  64. SaveCurrentInvoice() to return a boolean of
  65. success==true and failure==false.  Then
  66. the use of an exception, if any, would be
  67. internal to the saving algorithm, assuming
  68. that is the best expression of what needs
  69. to be done there.  Even that cannot be determined
  70. from your limited spec.
  71.  
  72.  
  73. > void SaveCurrentInvoice() throw ( SaveError )
  74. > {
  75. >      GetDataFromScreen() // always succeeds in this system
  76. >      try 
  77. >      {
  78. >           SaveDataToDatabase();
  79. >      }
  80. >      catch( SaveError err )
  81. >      {
  82.  
  83. was anything else expected to be done here?
  84.  
  85. >           throw err;
  86. >      }
  87. > }
  88.  
  89. This is most likely code bloat.  What purpose
  90. were you trying to serve by catching and rethrowing?
  91.  
  92.  
  93. > If this code seems OK, I have two comments:
  94.  
  95. > 1. It seems to increase the amount of code. However, it seems
  96. >    that the exception-handling would reduce code if there
  97. >    where many lines of code in a try block that could throw
  98. >    exceptions.
  99. > 2. This seems to be an issue that needs to be thought out well.
  100.  
  101. > P.S. The syntax may not be absolutely correct.
  102.  
  103.  
  104. > Thanx
  105. > LG
  106.  
  107. The key point is that looking for a "best expression"
  108. of a problem is an ideal and requires more information
  109. than taking any old valid expression of the problem.
  110. In general, we never know if the expression is best,
  111. but we often know that we have found a much better
  112. expression than our earlier attempts when we try.
  113. This leads to our growing an experience base of
  114. patterns of solutions that we recognize more readily
  115. and raise the quality of this form of endeavor as we
  116. attack new problems.
  117.  
  118. There is only a rather limited experience base with
  119. possible patterns involving exceptions.  Everyone,
  120. including the language definers are still groping with
  121. their basic implications.  As part of the "future shock"
  122. being caused adding them to the language, people
  123. are taking all kinds of very restricted views towards
  124. them and are applying them badly and then saying
  125. it is the fault of exceptions.  I am trying to add what
  126. seems to be needed tension in the other direction
  127. by making what seem to me to be basic obvious
  128. statements.
  129.  
  130. One such is stating that this is a control paradigm.
  131. Some want to say that it only an error paradigm.
  132. Well that is mixing what it is with how you want
  133. to [artifically, at least to me] limit use of it.  This
  134. difference has hurt how well it was concieved
  135. when it was added to the language.
  136.  
  137.  
  138. Good Day
  139. Dick
  140. Dick.Menninger@DaytonOH.ATTGIS.COM
  141.  
  142.